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REAL PARTY IN INTEREST 

The real party in interest is Juniper Networks, Inc. of Sunnyvale, California. 

RELATED APPEALS AND INTERFERENCES 

There are no related appeals and interferences. 

STATUS OF CLAIMS 

Claims 1-28 are on appeal in this case. Claims 1-28 are rejected under 35 U.S.C. 
1 12, first paragraph, asserting that the specification fails to describe the claimed subject 
matter in such a way to enable one skilled in the art to make and/use the invention. 

Claims 1-7 and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hankinson et al. (USPN 6,799,202) ("Hankinson") in view of Toporek et al. (USPN 
6,654,344) ("Toporek"). 

Claims 12-15, 17-21, 23 and 24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Abjanic (USPN 6,732,175) in view of Toporek, 

Claims 25-2 S are rejected under 35 U.S.C, 103(a) as being unpatentable over 
Baskey (USPN 6,732,269) in view of Toporek. 

STATUS OF AMENDMENTS 

No amendments have been filed subsequent to the Final Office Action mailed 
April 20, 2006 from which this Appeal has been made. 
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SUMMARY OF THE CLAIMED SUBJECT MATTER 

A concise simimary of independent claim 1,12 and 25 is provided within 
Appellant's Brief filed August 23, 2006. Per MPEP 1208, the Summary of the Claimed 
Subject Matter lia$ been omitted from this Reply Brief 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The first grounds for rejection to be reviewed on Appeal is the rejection of claims 
l.~2S under 35 U.S.C. 112, first paragraph, asserting that the specification fails to describe 
the claimed subject matter in such a way to enable one skilled in the art to make and/use 
the invention. 

The second grounds for rejection to be reviewed on Appeal is the rejection of claims 
1-7 and 22 under 35 U.S.C. 103(a) as being unpatentable over Hankinson et al. (USPN 
6J99,202) ("Hankinson") in view of Toporek et al. (USPN 6,654,344) ("Toporek"). 

The third grounds for rejection to be reviewed on Appeal is the rejection of claims 
12-15, 17-21, 23 and 24 under 35 U.S.C, 103(a) as being unpatentable over Abjanic 
(USPN 6,732,175) in view of Toporek. 

The fourth grounds for rejection to be reviewed on Appeal is the rejection of claims 
25-28 under 35 U.S.C. 103(a) as being unpatentable over Baskey (USPN 6,732,269) in 
view of Toporek. 
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ARGUMENTS 

The First Ground of Rejection 

Claims 1-28 are on appeal in this case. All claims are rejected under 35 U.S,C. 
112, first paragraph, asserting that the specification fails to describe the claimed subject 
matter in such a way to enable one skilled in the art to make and/use the invention. 
Appellants submit that, with respect to the first grounds of rejection, claims 1-28 stand or 
fall together. 

Response to the Examines 's Argument 

Claim 1 recites a load balancing acceleration device, With respect to claim. 1, the 
central issue for the rejection under 35 U.S.p. 1 12, first paragraph is the requirement that 
the device include a decryption engine and a load balancing engine that "bypass an 
application layer of a network stack by decrypting the data from the secure 
communication sessions of the clients and outputting tlie decrypted data to the associated 
server devices without processing the data with the application layer of the network 
stack " Similarly, with respect to claims 12 and 25, the claim elements at issue are 
"without processing the data packets with an application layer of a network stack " 

In the Examiner's Answer, the Examiner based his entire argument on the premise 
that secure socket layer (SSL) encryption and decryption always occurs at the application 
layer. Specifically, with respect to the rejection of claim 1 , the Examiner stated: 

The examiner acknowkdges that page 10 of the present application 
specifically states that "rather than trammitting packets up and down the TCP/IP 
stack a.s show in figure 2B, [the SSL accelerator of Figure 3] will perform the SSL 
encryption and decryption at the packet level before forwarding the packet on to 
its destination. " The examiner poiri'ts out to the board specifically in that 
statement that SSL encryption and decryption is being performed The examiner 
would also like to point out to the hoard that one of ordinary skill in the art 
knows that SSL Is performed in the application layer. Therefore, if SSL 
encryption and decryption is being performed, it has to be accomplished in the 
application layer. 

The Appellants continue to argue (on page 14 of the appeal brief) that 
there are three modes thai are described in great detail of pages 13-30 of the 
present application, including description of detailed flow charts showing how 
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these various modes implement SSL within the accelerator without requiring that 
the application data he reassembled at the application layer. 

The examiner asserts that all three modes are described by the Appellants 
in the present application incorporate SSL The examiner emphasizes that SSL 
occurs in the application layer. Th^ i^xaminer asserts that the Appellant-^ have 
not provided any details in the specification hoM^ SSL is being performed outside 
of the application layer (Ex. Ans., pp. 16-17) (emphasis added). 

Based on this premise, the Ejcaminer ignored the teaching of the present application and 
concluded that Appellants' claimed load-balancing acceleration device having a 
decryption engine and load balancing engine that bypass an application layer of a network 
stack is unsupported. The Examiner's position is erroneous for several reasons. 

First, Appellants respectfully disagree with the Examiner's position that SSL 
inherently always occurs at the application layer. The present application describes quite 
clearly that conventional client or server devices may implement SSL in the session layer 
(i.e., one layer below the application layer) to provide secure communication sessions 
between client devices and server devices, The present application describes applications 
executing within the application layer as producing outbound application-layer data that 
is passed down, to the session layer for en^fi^tion via SSL for the communication session. 
Inbound SSL communications are decrypted at the session layer and then passed up to 
the application layer. For example, the present application clearly states: 

Figure 2B illustrates how SSL functions in the Open Systems Interconnect 
(OSI) Reference Model and in typical accelerators. The web client transmits data 
to the accelerator 250 in an encrypted form to the secure port 443 o f the 
accelerator. In the client, the application layer protocol hands unencrypted data to 
the session layer ; SSL encrypts the data and hands it down through the layers to 
the network IP layer, and on to the physical layers (now shown). Normally, a 
server will receive the encrypted data and when the server receives the data at the 
other end, it passes it up through the layers to the session layer where SSL 
decrypts it and hands it olf to t>ie annlication layer fHTTP) . The same happens in 
the typical SSL accelerator within the accelerator, where the data is handed to the 
application layer, processed, then returned down, the stack from the HTTP layer to 
the IP layer for transmission to port 80 (in the clear) on the server coupled to the 
SSL accelerator. Once at the server, the data returns up the stack for processing in 
the application layer. Since the client and the SSL device have gone through the 
key negotiation handshake, the symtt|^tric key used by SSL is the same at both 
ends. 
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In essence, the HTTP packet must travel through the TCP stack four times, 
creating a latency and CPU overhead and. requiring full TCP stack support in the 
accelerator . . . .' 

This description provided by the present application is consistent with the industry- 
standard seven-layer Open Systems Interconnection (OSI) Basic Reference Model. As 
sliown in the evidence attached hereto in Appendix, E, the OSI model defines a layered, 
abstract description for communications and coinputer network protocol design, 
developed as part of Open Systems Interconnection (OSI) initiative. It is also called the 
OSI seven layer model. The layers, descrih^'d-l^elow, are, from top to bottoni, Application, 
Presentation, Session, Transport, Network, Data Link and Physical The evidence 
attached hereto clearly shows that SSL can be incorporated within the session layer or 
even the presentation layer, i.e., not the application layer. In other words, contrary to the 
Examiner's unsupported statement, SSL is not inherently always performed within the 
application layer. Such an unsupported statement cannot be used as a basis for ignoring 
the teachings of Appellant's specification and rejecting Appellants' claims as non- 
enabled under 35 U.S.C. 112, first paragraph. 

Second, the present application specifically describes techniques by which an 
acceleration device can perform encryption and decryption of data on a packet leve l and 
forward the data without handing off reassembled application-layer data up and down the 
TCP/IP stack to and from the application layer. To be clear, Appellants' claimed SSL 
acceleration device intercepts and processes!s$L data, but this processing does not occur 
at the application layer, as argued by the Examiner. Moreover, unlike prior art 
acceleration devices. Appellants' claimed device does not require tlie application layer be 
invoked after SSL processing when forwarding the data. Appellants' specification 
describes techniques by which the intercepted SSL data can be processed and forwarded 
at the packet level without requiring complete reassembly of the application-layer data, 
thus allowing the application layer to be bypassed. This process is shown, quite clearly 
shown in Figure 3 of the present application, reproduced and described at length in 
Appellants' Appeal Brief, pg. 13. 



' Present application, pg. 5, In, 16-pg. 6, In. 6 (emphasis added). 
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Moreover, the present application fiirtber describes in detail three distinct modes 
supported by Appellants' SSL acceleration device. These three modes are described in 
great detail on pp. 13-30 (eighteen pages) of the present application, including 
description of detailed flowcharts showing how these various modes implement SSL 
within the accelerator without requiring that. application data be completely reassembLe_d 
and passed up the entire network stack . As just one example of the d etailed technical 
disclosure within the present application, pg. 17, 11. 3-28 describes how SSL encrypted 
data can be processed at the packet level by utilizing a database and a buffer for 
processing TCP segments: 

The SSL accelerator 250 includes a TCP/SSL session database to track all 
communication sessions occurring through it. Each session will have one or more 
records associated with it, with each record comprising an association of the TCP 
session sequence and the SSL sequence. Hence, on receiving the initial SYN 
from client 100 at step 202, the SSL accelerator will create a database entry for the 
particular session, associating the TCP-SSL sequence number pairs. The data 
may be considered as a table, with each row in the table representing one entry in 
a given session. Hence, for each session, a typical record might include up to 
about 8-16 records, which include a TCP sequence number, SSL session 
number, an initiaJization vector (for DBS and 3DES) and an expected ACK. 

During decryption, the device may utilize portions of its memory to buffer 
segments as necessary for decryption. The number and size of tlie buffers will 
depend on the cipher scheme used' and the configuration of the packets, as well as 
whether the packets contain application data spanning multiple packets, referred 
to herein as multi-segment packets (and illustrated with respect to Figure 8), The 
SSL device can allocate SSL buffers as necessary for TCP segments. If, for 
example, application data having a length of 3000 bytes is transmitted via TCP 
segments having a length of 100 bytes, the device can, copy TCP segment 1 to a 
first SSL buffer, and start a timer, wait for packet 2 and when received, copy it to 
an SSL buffer and restart the timer, aiid finally when packet 3 is received, the SSL 
accelerator will copy it, decrypt all aj^plieation data, authenticate it and forward 
the data on in the clear. (An alterti£(ti!Ve, bufferless approach is described below). 
This section describes an example of how the SSL accelerator uses a TCP/SSL session 
database to track sessions, and TCP segments are buffered directly within SSL buffers 
and decrypted. Notably, an application-layer protocol, such as HTTP, is avoided. 

Furthermore, the present application expressly recognizes that implementing 
encryption and decryption within an intermediate acceleration device at the packet level 
(rather than using application layer data at the application layer) may result in certain 
problems. For example, the present application recognizes that SSL segments may span 
9 
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multiple TCP segments, which may result in problems if encryption and decryption 
occurs at the packet level as described by th^:' j^tescnt application. The present 
application, on pp. 25-29, then details certain' solutions to those problems so that the 
claimed acceleration device can perform encryption and decryption at the packet level 
As one example, the present application describes a unique bufferless or small buffer 
approach to handle the multisegment problem that may arise when SSL is implemented at 
the packet level by bypassing the application layer. In the bufferless approach, the 
present application describes the acceleration device as decrypting individual segments of 
multisegment SSL records, but not authenticated prior to being sent to the server. Only 
upon receipt of the packet carrying the last segment in the series is the data authenticated, 
however, individual SSL segments are not. This is but one example as to how the present 
application enables packet-level encryption and decryption that bypasses the application 
layer of the network stack. For the convenience of the Board, the solutions provided by 
the present application on pp. 25-29 are reprpduced in full below; 

There are numerous types d^commuriications problems which may occur 
at various stages of data transfer b 'm>een the SSL Accelerator, the client and the 
server. Some examples of these problems, and how the SSL device handles them, 
are set forth below. However, it will be understood that the number and type of 
errors which are possible in this sequence, and their attendant solutions, are too 
numerous to detail here. 

One type of problem is lost packets. Most lost packet cases can be 
recovered through use of the data structure mentioned above. As the data 
structure maintains the TCP sequence number, SSL sequence number, expected 
ACK and DES's Initialization vector, the SSL Accelerator device can roll back the 
SSL number to the previa us TCP number rece ived. 

A different problem occurs not packets are lost, but when there is an 
SSI segmentation problem. Segmentation problems may occur when, for 
example, 1 SSL record spans over 3 TCP segments, Le,: where SSL 
length=3000, and the TCP packet's length = 1000. This segmentation issue is 
illustrated in Figure 8. In this case, the Accelerator device cannot decrypt and 
authenticate the packet, since the MAC algorithm data will not arrive for 
another two segments. 

If. in the method of the invention, . the accelerator uses a memory buffer, 
(as described above with respect to] figure 5) the Accelerator can allocate an SSL 
buffer for 3000 bytes, copy TCP segment ] to the SSL buffer, and start a timer. 
When packet SSL/TCP packet 2 is received, it will be copied to an SSL buffer and 
the timer restarted Then M'hen packet 3 is received the SSL accelerator will copy 
it, decrypt it, allocate 3 TCP, segments, and copy HTTP data into it. This may 
then beforv'arded on in the clear. 

10 
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An alternative embodiment of the present invention utilizes a bufferless 
or small buffer approach to handle the multisegment problem. In the bufferkss 
approach, individual segments of multisegment SSL records are decrypted^ but 
not auihenticated prior to being sent to the server. Upon receipt of the last 
segment in the series (packet 3 in . the above example), the data will be 
authenticated, however, individual segments are not. This greatly reduces the 
hardware requirements of the devtf:^ be requiring little or no buffer memory 
allocated to multi segment SSL pa<0ts. For non-block ciphers, such as RC2 and 
RC4, this decryption can be performed . on the fly. However, for block ciphers 
such as 3DES/DES, some buffering must occur. This is due to the fact that data 
for these ciphers must be combined from blocks. In these cases, only part of the 
data is decrypted and the rest is moved to the next segment. Hence, if there are 
more than two segments, and the encryption cipher is DES> with 8 byte blocks, the 
SSL device will buffer up to 7 bytes with additional 7 bytes sequentially moved 
until the last segment, with the last, segment always having enough room, to 
accommodate the data without breaking the server's M3S. In an exemplary 
design, the operational modes are configurable by a user so (hat the sacrifice of 
whether to potentially compromise security by not authenticating each packet is 
the user 's choice. Nevertheless, because for block ciphers it is impossible to know 
the padding length before decryption is finished and the padding length is used to 
start calculating authentication, then authentication of the data in the multi- 
segment SSL data does occur upon receipt of the last segment - and the receipt of 
the MAC algorithm data and one is required to store all decrypted data into a 
buffer. If however, the data cannot be authenticated at (hat time, the SSL device 
will send a reset to the server and an ALERT to the client, indicating a problem 
with the session ha.-; occurred and:,}i.otifying the user. For block ciphers, the 
system does some buffering, bitt.thi^i^inimal buffering will reduce latency 

Another issue may occur 'yWhm a "small" window problem occurs. 
Normally, communications between the Sever to Client occur as shown in Table 
1: 



■11 
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TABLE] 



Client 


SSL Accelerator 


Server 










encrypt 

^SSL TCF443 1^0 








^ TCP 30 2-1000 




Encrypt . 

^ LiijL iL-V ^fJ ^—1 iJUU 








^TCPSO 3=2000 




Encrypt 

<-SSL.,TCP443 3^2000 




TCP443 ACK^SOOO ^ 








TCP89 ACK^3000 ^ 





The small window problem may occur when, for example, the 
ServerMSS^lOOO, but Client understands an MSS'=900, In this situation, if the 
client sends an ACK W=3000, the SSL accelerator will understand it is going to 
receive 3. WOO byte segments. This problem, is illustrated in Table 3. In Table 3, 
the server 'y packet length is, far example, 100 bytes. So instead of receiving 3, 
WOO byte segments, the SSL accelerator will receive 30, 100 byte segments from 
the server. Once the SSL accelerator adds the SSL overhead, which in this 
example is 100 bytes, the packet Size to be returned to the client doubles for each 
packet from the server: 
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TABLE 2 



Client 


SSL Accelerator 


Server 


AckW=mO 








Ack W=2700 (SSL 
expect itig 3 I QOOSegments) 








<--TCP J^^O, 1=100 




Eyicrj'pt 

<-SSLTCP 1=200 








<- TCP 2-^100.1=100 




Encrypt 

SSL TCP 2=200. I =200 








<- TCP 3=200, 1=100 




Encrypt 

<-- SSL TCP 3=400. I = 200 






□ 

n 








^~ il^r M — J'iUu, t—iUU 




Encrypt 

SSL TCP 4^2800, I ^ 200 








<- TCP 15=1500, 1=100 




Encrj'pt :,■ ■ 

SSL TCP'. 5^3000. 1 = 200 








<- TCP 16=1600. 1^1 00 



The SSL accelerator cannot send TCP packet 16 because client's window 
is full already (with 15, 200 byte packets). 

In this case, the SSL accelerator will buffer the Server's responses, 
starting from this point so that when a next TCP ACK=3000 is received from the 
client, the SSL accelerator will take the server response (packet 16) from the 
buffer, encrypt it and return it to the client. 

If one of the foregoing problems occurs when the SSL accelerator is in a 
mode which does not support that particular type of communication, the SSL 
accelerator may switch modes to enable that type of communication to be 
handled. 

For at least these reasons, one of ordinaty skill would appreciate that the present 
application enables an acceleration device having a decryption engine and a load 
balancing engine that "bypass an application layer of a network stack by decrypting the 
data from the secure communication sessions' of the clients and outputting the decrypted 
data to the associated server devices without processiDg the data with the application 
layer of the network stack." Similarly, with respect to claims 12 and 25, the present 
application enables an SSL acceleration device that performs SSL encryption and 
operation, and selects a destination server "without processing the data packets with an 
application layer of a network stack." 
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Appellants' specification describes the claimed subject matter in such a way to 
enable one skilled in the art to make and use the invention. Tlie Examiner's position that 
SSL must inherently be performed at the aptjlication layer ignores Appellants' specific 
teachings of techniques for processing SSL; da^a with an intermediate device at the packet 
level without requiring that the data be reassembled and handed-off to the application 
layer. The rejection under 35 USC 1 12, first paragraph, should be withdrawn. 

The Second Ground of Rejection 

Claims 1-7 and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hankinson et al. (USPN 6,799,202) ("Hankinson") in view of Toporek et al. (USPN 
6,654,344) ("Toporek"). Claim 1 requires an acceleration device in which a decryption 
engine and the load balancing engine bypass an application layer of a network stack by 
decrypting the data from the secure communication sessions of the clients and outputting 
the decrypted data to the associated server devices without processing the data with the 
application layer of the network stack. 

Response to the Examiner 's Argument 

In the Examiner's Answer, the Examiner pointed to no teaching in the prior art of 
an acceleration device in which a decryption engine and the load balancing engine bypass 
an application layer of a network stack by decrypting the data from the secure 
communication sessions of the clients and outputting the decrypted data to the associated 
server devices without processing the data with the application layer of the network stack. 
Instead, the Examiner argued that the cited references teach load balancing (Ex. Ans., pg, 
1 8) and that bypassing the application layer for load balancing would inherently result in 
increased speed {Id., pg. 20). This analysis overlooks the requirement that Appellants' 
claimed acceleration device must be capable of decrypting the data from the secure 
communication sessions of the clients and outputting the decrypted data to the associated 
server devices without processing the data with the application layer of the network stack. 

As set forth in Appellants' Appeal Brief, even in combination, Hankinson in view 
of Toporek fail to provide any teaching releyiant to providing encryption and decryption 
Of secure data within an acceleration device in a manner that bypasses the application 

14^ 
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layer. Toporek describes a mechanism for controlling data flow from a satellite. The 
portion o f Toporek cited by the Examiner describes a satellite gateway that merely relays 
information between a client and a server. The related information is not processed by 
the satellite gateway other than to control the rate of fiow through the link. Toporek 
indeed states that the relayed information can flow through the satellite gateway at the 
network layer and bypass the transport and application layers, but this is merely because 
the data is not processed whatsoever. There is no teaching in Hankinson in view of 
Toporek as to how a device could decrypt secure data using a process that bypasses the 
application layer. Even if the Examiner's characterization of Toporek is correct that 
Toporek "allows the network layer to communicate directly to the physical layer " the 
combination of references still provides no teaching as to how the application-layer 
(which is above both the network layer and the physical layer) could be avoided for 
functions like SSL that traditionally require the application-layer.^ 

More specifically, Appellants' claitn 1 requires decrypting the data from the 
secure communication sessions of the clients without processing the data with the 
application layer of the network stack. Hankinson describes a distributed operating 
system and makes only a passing reference to SSL, and the Toporek device only relays 
information. This combination provides no teaching whatsoever as to how a secure client 
communication could be decrypted, such as.,SSL. In fact, the combination does not 
suggest that SSL would be processed any d'ijferently whatsoever. According to Toporek, 
satellite communications that need not be processed can be relayed without processing. 
According to Hankinson, network components can be distributed to multiple devices. 

The Examiner's conclusion of obviousness is based entirely on the unsupported 
assumption that the Hankinson in view of Toporek could somehow achieve an 
acceleration device capable of decrypting secure client communications without 
processing the secure communication at the application layer. It is important for the 
Examiner to appreciate that SSL and other secure communications of application data 
encrypt blocks of application data to form secure records above the packet level. Once 
formed, the secure records are passed down the network stack to the network layer where 



= Office Action, pg. 5, where the Examiner cites TopOtai: at col. ) 1 , II. 22-33. 
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the secure records are split into packets. Decrypting SSL records without processing the 
records at an application layer is a non-trivial problem that is not remotely answered or 
suggested by any of the references. As one example, handling SSL communications of 
encrypted application data may require reassembly of secure records of application data 
that span multiple packets. Techniques for addressing these and other issues associated 
with secure client communications without processing the packets at the application layer 
are described throughout the application. See, e.g., pp. 17 and 26, which describe 
techniques by which Appellants' acceleration device is able to decrypt SSL records that 
span multiple packets without processing the packets at the application layer. 

With respect to encryption, Hankinson merely notes that the system may support 
SSL. Hankinson provides no suggestion thtit'SSL is supported in any manner that is 
different from the prior art. Toporek provides no mention of SSL or decrypting secure 
communications whatsoever. Therefore, there is no reasonable expectation that the 
Hankinson web server could be successfiilly modified in view of Toporek so as to 
somehow incorporate the function of decrypting data from a communication session 
without processing the data at the application layer. There is a significant gap in the 
teachings of the references as to how such a feature may even be implemented. The fact 
that Hankinson makes a passing reference to SSL and that Toporek describes a 
mechanism for relaying packet information without processing the packets whatsoever 
provides no enabling description of how encrypted communications could be decrypted 
with, an acceleration device without processing the secure data at the application layer. 

The Examiner's suggestion that the Hankinson operating system that load 
balances processing task could somehow be modified in view of Toporek to load balance 
decrypted data without processing the decri^ted data at the application layer again 
glosses over significant gaps in the teachings of the references. 

The Third Ground of Rejection 

Claims 12-15, 17-21, 23 and 24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Abjanic (USPN 6,732,175) in view of Toporek. Claim 12 requires, 
without processing the data packets with an application layer of a network Stack, selecting 

16 
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with the acceleration device at least one of the plurality of servers in the enterprise based, 
on a load, calculation including processing sessions of other servers in the enterprise and 
associating the selected server vvith a communications session from the one of the clients. 

Response to the Examiner's Arguments 

The Examiner argues that Abjanic is not an application-layer content-based 

apparatus (Ex. Ans., pp. 21). This, however, is in direct contrast with the disclosure of 

Abjanic that clearly states that the network apparatus includes a content-based message 

director (e.g., vVMZ director) to route or direct messages received from the network to one 

of the processing nodes based upon the application data, including business transaction 

information.^ In direct contrast to the elements of claim 21, Abjanic malces clear that the 

described apparatus is an application-layer content-based switching apparatus. Abjanic 

provides numerous examples of how application layer data (XML data in this case) is 

extracted using the HTTP protocol (which is an application-layer protocol) in order to 

make forwarding decisions. Below is one t?npf example: 

The application data is provided after the HTTP header, and in this 
example is provided as XML data, . : . [Tjhe present invention is directed to a 
technique to perform switching at a network apparatus based upon the 
application data, such as XML data (which includes business transaction 
information).^ 

HTTP headers and XML data are only available at tlie application layer upon reassembly 
of application-layer data. Abjanic fails to teach or suggest mechanisms by which a load 
balancing acceleration device can, without processing the data packets with an 
application layer of a network stack, selecting with the acceleration, device at least one of 
the plurality of servers in the enterprise based on a load calculation including processing 
sessions of other servers in the enterprise and associating the selected server with a 
communications session from the one of tlie clients, 

In response, the Examiner also justifies the rejection based on the fact tliat 
Abjanic describes an SSL accelerator (Ex. /^s'., pp. 21). The Examiner also argues that 
Abjanic includes a traffic manager that perf'oniis acceleration and load balancing based on 



' Abjanic at Summary. 
Abjanic at coi, 6, II. 1-25. 
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liable b 



business transactions, purchase orders, stock quotes 
transaction information." (Ex, Ans., pp., 22). This 
layer information and would require reassembly of 
business transaction infonnation would not be avail 
this reason, Abjanic specifically states that,appli 
content-based switching. : , 

ThuSj Abjanic provides no suggestion ol 
decryption, in any fashion different from, the prior art; 
handing off reassembled application-layer data to the 
contrary, Abjanic expressly requires application-layer 
of Abjanic in view of Toporek fails to provide any 
the secure protocol with the acceleration, device to 
without processing the data packets with an application 
with the acceleration device at least one of the pluralpy 
on a load calculation including processing sessions 
associating the selected server with a commumcatioiis 
as required by claim 12, 



stock trades, and other "business 
iiiformation, however, is application- 
application-layer data. Certainly, 
below the application layer. For 
i-layer data is required for the 



ptovide 



The Fourth Grburid of Rcicction 



Claims 25-28 are rejected under 35 U.S.C 
Baskey (USPN 6,732,269) in view of Toporek. 
plurality o f server devices, and an intermediate 
and the server devices. Claim 25 further requires 
request from the client device for a secure communitation 
request, the intermediate device establishes a secure 
client device, selects one of the server devices based 
the server devices without processing the request 
stack, and establishes a non-secure communication 
device. 



Claim 
e device 



twith 



' Abjanic at col, 6, H. 1-25. 



Tperfbrming SSL encryption and 
, i.e., at the session layer and 
application layer. In fact, quite the 
data. Therefore, the combination 
teaching for decrypting data packets of 
le decrypted packet data, and 
layer of a network stack, selecting 
of servers in the enterprise based 
c|f other servers in the enterprise and 
session from the one of the clients, 



lb3(a) as being unpatentable over 
25 requires a client device, a 
coupled between the client devices 
the intermediate device intercepts a 
session, and in response to the 
communication session with the 
on resource loading experienced by 
an application layer of a network 
Session with the selected server 
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Response to the Examiner 's Arguments 

The Examiner's basis for the rejection of claims 25-28 appears to be based, 
squarely on the premise addressed above with respect to claim 1, i.e., that SSL must 
always be performed within the application layer. For example, the Examiner argues that 
Baskey describes two different connections that utilize an SSL proxy server (Ek. Ans., 
pg. 24). As discussed in Appellants' Appeal Brief, the Baskey approach explicitly 
requires that secure data travel two liill networking stacks, including the application layer, 
and Baskey fails to describe any other mechanism for implementing the SSL proxy, The 
satellite relay function of Toporek, where packets are not even processed, provides no 
enabling teaching whatsoever as to how the Baskey device could be modified so that SSL 
functions could still be implemented yet in a manner that avoids the application layer. 
Nothing in Baskey or Toporek bridges this significant gap as to how the Toporek packet 
relay function that bypasses both the transport and the application layer could possibly be 
used within a load-balancing, full proxy device, such as the Baskey device. 

For at least these reasons, the references fail to establish a prima facie case for 
non-patentability of Appellants' claims under 35 U.S.C. 103(a). Withdrawal of this 
rejection is requested. 

Conclusion of Arguments 

The Examiner erred in rejecting Appellants' claims under 35 U.S.C. 112, first 
paragraph and 35 U.S.C, 103(a). Reversal of , these rejections and allowance of the 
pending claims are requested. 



Respectfully submitted, 



Date; 

.TulvlO. 2007 



By: 




ShuTTialcer & SiefFert, P.A. 
1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 



Name: Kent J. Sieffert 
Reg, No.: 41,312 



Telephone: (651) 735-1100 ext. 341 
Facsimile: (651)735-1102 
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APPENDIX I: CLAIMS ON APPEAL 

Claim I (Previously Presented): A load balancing acceleration device, comprising: 
a processor, memory and communications interface; 

a TCP communications manager capable of interacting with a plurality of client 
devices and server devices simultaneously via the communications interface; 

a secure communications manager to negotiate a secure communication session 
with one of the client devices ; 

an encryption and decryption engine instructing the processor to decrypt data 
received via the secure communication session and direct the decrypted data to one of 
said server devices via a second communication session; and 

a load balancing engine associating each of said client devices with a respective 
one of said server devices based on calculated processing loads of each said server 
devices, 

wherein the decryption engine and the load balancing engine bypass an 
application layer of a network stack by decrypting the data from the secure 
communication sessions of the clients and outputting the decrypted data to the associated 
server devices without processing the data with the application, layer of the network stack. 

Claim 2 (Previously Presented): The device of claim 1 wherein the TCP 
communications manager provides an IP address of an enterprise to said secure 
communications manager, and each of said plurality of servers devices is associated with 
the enterprise. 

Claim 3 (Previously Presented): The device of claim 2 wherein the secure 
communications manager negotiates a secure communication session with each of said 
plurality of client devices over an open network. 
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Claim 4 (Previously Presented): The device of claim 3 wherein the TCP 
communications manager negotiates a separate, open communications session with one 
of the plurality of servers devices associated' With the enterprise for each secure 
communications session negotiated with the a client devices based on the associations of 
said client devices to said server devices by said load balancing engines. 

Claim 5 (Previously Presented): The device of claim 1 wherein the encryption and 
decryption engine decrypts the data on a packet level by decrypting packet data received 
on the communications interface via the secure communications session to extract a 
secure record, decrypting application data from the secure record in the packet data, and 
outputting the decrypted application data from the secure record to the one of said server 
devices via the second communication session, without processing the application data 
with ffii the application layer of the network stack. 

Claim 6 (Previously Presented): The device of claim 5 wherein the load-balancing 
engine selects the second communication session. 

Claim 7 (Previously Presented): The device of claim 1 wherein the TCP 
communications manager responds to TCP communications negotiations directly for an 
enterprise. 

Claim 8 (Previously Presented): The device of claim 1 , 

wherein the TCP communications manager receives packets from the client 
devices, and 

wherein the TCP communications manager changes destination IP addresses for 
the packets to IP addresses for the server devices. 
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Claim 9 (Previously Presented): The device of claim 8, 

wherein the TCP communications manager maintains TCP communication 
sessions with the server deviceSj and 

v^rherein the secure communications manager negotiates a secure communication 
session for each TCP communications session. 

Claim 1 0 (Original): The device of claim ^ wherein the secure communications manager 
responds to all secure communications with each client device. 

Claim 1 1 (Previously Presented): The device of claim 9 wherein the secure 
communications manager changes a destination IP address for each packet to a server IP 
address. 

Claim 1, 2 (Previously Presented): A method for performing acceleration of data 
communications between a plurality of customer devices attempting to communicate with 
an enterprise having a plurality of servers, comprising: 

providing an intermediate acceleration device enabled for secure communication 
with the customer devices, wherein the acceleration device has an IP address associated 
with the enterprise; 

receiving with the acceleration device communications directed to the enterprise 
in a secure protocol from one of the customer devices; 

decrypting data packets of the secure protocol with the acceleration device to 
provide decrypted packet data; 

without processing the data packets with an application layer of a network stack, 
selecting with the acceleration device at least one of the plurality of servers in the 
enterprise based on a load calculation including processing sessions of other servers in the 
enterprise and associating the selected server with a communications session from the one 
of the clients; and 

forwarding the decrypted packet data from the acceleration device to the selected 
server of the enterprise. 
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Claim 13 (Original): The method of claim 12 further including the steps of: 
receiving application data from the selected server of the enterprise; 
encrypting the application data received from the selected server; and 
forwarding encrypted application data to the customer device. 

Claim 14 (Previously Presented): The method of claim 12 v^fherein the step of 
receiving communications directed to the enterprise includes receiving with the device 
communications having a destination IP address of the enterprise. 

Claim 1 5 (Previously Presented): The method of claim 12 further including the step of 
negotiating the secure protocol session with the customer device by responding as the 
enterprise to the customer devices. 

Claim 1. 6 (Previously Presented): The method of claim 1 2 further wherein the step of 
forwarding comprises: 

modifying a destination IP address of data packets fi-om an IP address associated 
with the enterprise IP to an IP address for the selected server. 

Claim 17 (Previously Presented): The method of claim 1,2 wherein the step of 
forwarding comprises: 

establishing an open communication session from the acceleration device to the 
selected server, and 

mapping the decrypted packet data to the open communication session established 
with the selected server. 

Claim 1 8 (Previously Presented): The method of claim 1 7 wherein the open 
communication session is established via a secure network. 
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Claim 19 (Previously Presented): The method of claim 12 wherein the step of 
receiving comprises: 

receiving encrypted, data having a length greater than a TCP segment carrying said 
data; and 

v^rherein said step of decrypting comprises: 

buffering the encrypted data in a memory buffer in the acceleration 
device, the buffer having a length equivalent to the block cipher size necessary to 
perform the cipher; and 

decrypting the buffered segment of the received encrypted data to provide 
decrypted application data. 

Claim 20 (Previously Presented): The method of claim 19 further including the step of 
authenticating the data on receipt of a final TCP segment on a packet level without 
processing the application data with the aF>:application layer of the network a TCP/IP 
stack. 

Claim 21 (Original): The method of claim 19 further including the step of generating an 
alert if said step of authenticating results in a failure. 

Claim 22 (Previously Presented): The device of claim 1 , wherein the device 
comprises a network router- 



Claim 23 (Previously Presented); The method of claim 12, wherein decrypting data 
packets comprises decrypting the data packets at a packet level of the network a TCP/IP 
stack. 
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Claim 24 (Previously Presented): The method of claim 1 2, wherein decrypting data 
packets comprises: 

decrypting the data packets to extract a secure record, 

decrypting application data from tlie secure record^ and 

authenticating the application data Without processing the application data with m 
the application layer of the network stack. 

Claim 25 (Previously Presented): A system comprising: 
a client device; 

a plurality of server devices; and 

an intermediate device coupled between the client devices and the server devices, 
wherein the intermediate device intercepts a request from the client device for a 
secure communication session, and 

wherein, in response to the request, the intermediate device establishes a secure 
communication session with the client device, selects one of the server devices based on 
resource loading experienced by the server devices without processing the request with an 
application layer of a network stack, and establishes a non-secure communication session 
with the selected server device. 

Claim 26 (Previously Presented): The system of claim 25 , wherein the intermediate 
device receives encrypted data from the client device via the secure communication 
session, decrypts the data and forwards the decrypted data to the selected server device 
via the non-secure communication session. 

Claim 27 (Previously Presented): The system of claim 25, wherein the intermediate 
device receives unencrypted data from the selected server device via the non-secure 
communication session, encrypts the data and forwards the encrypted data to the client 
device via the secure communication session. 



Claim 28 (Previously Presented): 
device comprises a network router. 



The system, of claim 25, wherein the intermediate 
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OSI Reference Model— The ISO Model of Architecture for 
Open Systems Interconnection 



HUBERT ZIMMEHMANN 

(Invited Paper] 
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1, INTRODUCTION 

IN 1977, th« International Organiaatlon for Standardisation 
(ISO) recognisud the specisJ and utgent need for standaids 
fot heterogeneows iijforrnntic networks and decided to create 
6 new subcommittee (SCl6) for "Open Systems Intercon- 
nection." 

The initial development of computer nctwofka had been 
fostered by experimental networks such as ARPANET [ll.;. 
or CYCLADES [2], iinmedlately followed by computer 
manufacturer [3] , [4] . While experimental networks were 
conceived as heterogeneous from the very beginmng, each 
manuftcturer developed his own set of conventions for inter- 
connect.) ng his own equipments, referring to these as his 
"network architecture." 

The universal need for interconnecting systems from 
diffeiont manufacturers rapidly became apparent [5] , leading 
ISO to decide for the creation of SCI 6 with the objective to 
come up with standards required for "Open Systems Inter- 
connection/' The term "Open" was chosen to emphasize the 
fact that by cotiforffling to thoae international ,«andards, a 
system will be open to all other systems obeying the same 
standards through out the world . 

The flret meeting of SCl6 was held in March 197S, aJid 

M-nuncript rcHsWed Augujl S. 1979; revbied hnvBiy 16. 1980. 
The auther l« with IRIA/Latwrii, Rocquenceuit, Fnnco, 



initial discussions revealed [6] that a consensus could be 
reached rapidly on a layered architecture which would satisfy 
most requirements of Open Systems Interconnection with 
the capacity of being expanded later to meet new require- 
ments, SClfi decided to give the highest priority to the 
development of a standard Model of Architecture which would 
constitute the framework for the development of standard 
protocols. After less than IS months' of discussions, this 
task wan completed, and the ISO Model of Architecture 
called the Reference Model of Open Systems Intereonnectloii 
(7] was transmitted by SCIG to its parent Tecjuilcal Com- 
mittee on "Data Processing" (TC97) along with recommenda- 
tions to officially start a number of projects for developing 
on this basis en initial set of standard protocols for Open 
Systems Interconnection. These recommendations were 
adopted hy TC97 at the end of 1979 as the bajij for following 
development of standards for Open Systems Interconnection 
within ISO. The OSI Reference Model was also recognized by 
CCITT Rapporteur's Group on Public Data Network Services, 

The present paper describes the OSI Architecture Model 
RS it has been transmittad to TC97- Sections II-V Introduce 
concepts of a layered architecture, along with the associated 
vooflbulaiy defined by SCI 6. Specific use of those concepts 
in the OSI seven layers architecture are then presented in 
Section VI, Finally, sorne Indications on the likely develop- 
ment of OSI standard protocols are given in Section VII. 

" ffots on m "Interconnection A rehitecture " 

The basic objective of SCl6 is to standardise the rules of 
interaction between Interconnected systems. Thus, ortJy the 
external behavior of Open Systems must conform to OSI 
Architecture, while the internal organiiatlon and functioning 
of fiaeh individual Open System is out of the scope of 051 
standards since these are not visible from other systems with 
which it is interconnected [8] . 

It should be noted that the same principle of restricted 
vlslbUjty is used in any manufacturer's network aichitectuie 
in order to permit interconnection of systems with different 
structures within the same network. 

These considerations lead SCI 6 to prefer (he term of 
"Open Systems Interconnection Architecture" (OSIA) to 
the tetm Of "Open Systems Architecture" which had been 
used previously and was felt to be possibly misleading. How- 
ever, for unclear reasons, SCI 6 finally selected the title 
" Reference Model of Open Systems Interconnection" to 
refer to this JntftTConnectlon Architecture, 



0090-6778/80/0400-0425100.75 © 1980 IEEE 



07/10/2007 16:46 6517351102 



SHUMAKER & SIEFFERT 



PAGE 28 



IEEE TRANSACTIONS ON COMMUNICATIONS, VOL. COM-IS, NO. 4, APRIL 1*60 




Fig. 2. An e:<4niple of OSI TBprrjSBTtatlon of Inysfing. 



Fig, 1, Network lny Bring, 

II, GENERAL PRINCIPLES OF LAYERING ' 
Layerini is a structuring technique which permits the 
network of Open Systems to be viewed as logically composed 
of a succession of layers, each wrapping the lower layers and 
isolating them from tha higher layers, as Exemplified in Fig, 
J, 

An alternative but equivalent illustration of layering, used 
in particular by SCI 6 is given in F)g. 2 where succassive 
lay en are' represented in a vertical sequence, with the physical 
media for Open Systehis Interconnection at the bottom. 

Each individual system itself is viewed as being logically 
composed of a succession of subsystems, each corresponding, 
to the intersection of the system with a layer. In other words, 
a layer is viewed as being logically composed of subsysteins 
of the same, rank of all interconnected systems. Each sub- 
system is, ih tum, viewed as being made of 'one or several 
entities. In other words, each layer is made of entities, each of 
which belongs to one system. Entities in the same layer are 
teifmed peer entities. 

For simplicity, any layer is referred to as the {N) layer, 
while its next lower and next higher layers are referred to as 
the (JV - i) layer and the (N + I) layer, respectively. The 
same notation ia used to designnte all concepts relating to 
layers, e,g„ entities in the (AO layer are termed (AO etitifies, 
as illustrated in Figs, 3 and 4, 

The basic idea of layering is that each layer adds value to 
servicss provided by the set of lower layers in such ft way that 
the highest layer is offered the set of services needed to run 
distributed applications. Layering thus divides fhe total 
problem into smaller pieces. Another basic principle of layering 
Is to ensure independence of each layer by defining services 
provided by a layer to the next higher layer, independent of 
how these services are performed. This permits changes to' be 
made in the way a layer or a set of layers operat?. provided 
they still offer the same service to the next higher layer. 
(A more comprehensive list of criteria for layering is given in 
Section VI,) This technique is similar to the one used jn 
structured programming >vhere only the functions performed 
by a module (and not its internal functioiiing) are known by 

Except for the highest layer which Operates for its own 
purpose, (N) entities distributed among the interconnected 
Open Systems work collectively to provide the (N) service 



Fis-3. Sj'stema, layers, m 




Fig. 4. Entitles, nervice Htcffl! pulnta (SAP's), and pFOtomls, 



to (A'^ + 1) entities as illustrated in Fig, 4. In other words, the 
(/V) entities add value to the (N ^ I) service they get from the 
(N - 1) layer and offer this value-added service, i.e., the 
(AO service to the (Af + 1) entities. 

Communication between the (AT -I- 1) entities make exclusive 
use of the (AO services. In paftjcular, direct communication 
between the (JV + 1) entities in the same system, e.g., for 
sharing resources, is not visible from outside of the system and 
thus is not covered by the OSI Architecture, Entities in the 
lowest layer communicate through the Physical Media for 
OSI, which could be considered as forming the (O) layer of 
t.he OSl Architecture. Cooperation between the (AO entities 
is ruled by the (AO protocols which precisely define how the 
(AO entitles work together using the (Af ^ 1 ) services to per- 
form the (AO functions which add value to the (A^- 1) service 
In Older to offer the (N) service to the (N.+ 1 ) entitles. 

The (AO services are Offered to the (,N + 1) entities at 
the (/{) service access points, or (N) SAP's for short, which 
represent the logical iiiterfaces between the (AO entities and 
the (A^ + 1) entities. An (N) SAP can be served by only one 
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Pig. S. ConnucHons and connection andpaints (CEF'a). 

(JV) entity afld used by only ore {N + 1) entity, but one. 
(JV) entity can serve several (AQ SAP's and one(jV + I) entity 
can use several (A^ SAP's. 

A common service offered by all layers consists of pro- 
viding associations between peer SAf 's ivliich can be used in 
particular to transfer data (it can, for instance, also be used 
to .synchronize the served entities participating in the asso- 
ciation). More precisely (see Fig. 5), the {N) layer offers 
(N) connections between (N) SAP's ss part of the (N) services. 
The most usual type of connection is the point-to-point 
connection, but there are also multiendpoint connections 
which correspond to multiple associations between entitles 
(e.g., broadcast communication). The end of an (AO con- 
nection at an (AO SAP is called an {N) connection endpoint or 
(/V) CEP for short. Several connections may coexist between 
the same pair (or rt-tuple) of SAP's. 

Note: In the following, for the sake of simplicity, we wiH 
consider only point-to-point connections. 

in. IDENTIFIERS 

Objects within a layer or at the boundary between adjacent 
layers need to be uniquely identifiable, e.g., in order to estab- 
lish a connection between two SAP's, one must be able to 
identify them uniquely. The OSI Architecture defines identi- 
fieri for entities, SAPs, and connections as well as relations 
between these identifiers, as briefly outlined below. 

Each (AO entity is identified with a s^obai title^ which is 
unique and identifies the same (/V) entity from anywhere in 
the network of Open Systems. Within more limited domains, 
an (jV) entity can be identified wjtlia local title which uniquely 
identifies the (AO entity only in the domain, For Instance, 
within the domain corresponding to the (AO iayef, (AO entities 
are identified with (N) global titles which are unique within 
the (AO layer. 

Each iN)SAF is identified with an (AO address which 
uniquely identifies the (AO^SAP at the boundary between 
the■(^) layer end the (A^ + 1) layer. 

The concepts of titles and addresses are illustrated in 
Fig, 6. 

Binding between (AO entities and the (AT - 1) SAP's they 
use (i.e., SAP's through which they can access each other and 
communicate) are translated into the concept of (AO directory 
which indicates correspondence between global titles of 
(AO entities and (N) addresses through which they can be 
reached, as illustrated in Fig. 7. 

' ThE (aim "title" has bBen preferred to the term "nsme" which Is 
viewed as bearing a mote general nteanlnj, A titit is equlvaJent to. an 
eptity name. 




,Fi(t, 6. Titles, addresses, and CEP-identifiefs. 



Fig. 7. Example of an (AO-dlrcctery, 

Correspondence between (AO addresses served by an (AO 
entity and the (N ~ 1) addresses used for this purpose is 
performed by an (AO mapping function. In additioit to the 
simplest case of one-to-one mapping, mapping may, in particu- 
lar, be hierarchical with the (AO address being made of an 
{N - 1) address and an (AO suffix. Mapping may also be 
performed "by table." Those three types of mapping are 
illustrated in Fig. 8. 

Each (AO CEP is uniquely identified within its (AO SAP 
by an (AO CEP identifier which is used by the (AO entity and 
the (A' -H 1) entity on both sides of the (AO SAP to identify 
the (AO connection as illustrated in Fig. 6. This is necessary 
since several (AO connections may end at the same (A) SAP. 

IV. OPERATION OF CONNECTIONS 
A. Ettabtishment and Release 

When an C^V + 1) entity requests the establishment of an 
(AO connection from one of the (JV) SAP's it uses to another 
(AO SAP, it must provide at the local (AO SAP the {N) address 
; . of the distant (AO SAP. When the (AO connection is established, 
both the (JV 1) entity and the (AO entity will use the (AOCEP 
identifier to designate the (A) connection. 

(AO connections may be established and released dynamically 
on top of {N - 1) connections. Establishment of an (AO 
connection implies the availability of an (A^- 1) connection 
between the two entities. If not available, the (A^ - 1) con- 
nection must be estabUshcd. This requires the availability of 
an (A^ - 2) connection. The same consideration appHes down- 
wards until an available connection is encountered. 

In some cases, the (A) connection may be established 
simultaneously with its suppofting(jV- 1) connection provided 
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the - 1) connection establishment service permits (N) 
entities to exchange information jieceaaiy to estaljUsh the 
(iV) connection. 

B. Muttiptexing and Splittins 

Three particular types of construction of {J^ connections 
on top of (Af - I) connections arc distinguished. 

1) One-to-one correspondence where each (N) connection 
is buUt on one (N - I) connection. 

2) Multiplexing (referred to as "upward multiplexing" in 
[7]) where sen era] (JV) connections are multiplexed on one 
single [N—)) connection. 

3) Splitting (referred to as "downward multiplsxlng" in 
[7] ) where one single (/V) connection is built On top of several 
(iV - 1) connection, tlw traffic on the (^V) connection being 
divided between the various (A" - 1 ) connections. 

These three types of correspondence between connections 
in adjscent layers are Ulusttated in Fig, 9 . ^ . 

C. Data Trmtfer 

Information is transferred in various types of data units 
between peer entities and between entities attached to a 
specific service accea point- The data units are dcflned below 
and the interrelationship among several of them is illustrated 
in Fig- 1 0- 

{N) PKtoeol Control InfortnstiQn is infomiation exchanged 
between two (AQ entitiea, using an (.A^ ^ 1) connection, to 
coordinate their joint operation. 

(AO Ua&r Data is the data transferred between two (AO 
entities on bshsilf of the (Af + 1) entitles for whom the (JV) 
entities are providing services. 

All (AO Protocol Data Unit is a unit of data which contains 
(AO Protocol Control Information and possibly (AO User 
Data, 

(JV) Interface Control Information is infonnation excliangecl 
between an (A^ + I) entity and an (JV) entity to coordinate 
their joint operation. 

(AO /nterfacf Data is inforniation transferred from an 
(W + 1) entity to an (AO entity for transmission to a cpr- 
respondent (A^ + 1) entity over an (^ connection, or con- 
versely, information transferred from an (AO entity to an 
(A^ + 1) entity which has been received over an (AO cdh: 
nectlon from a correspondent (W + t) entity. 

(JV) (nterfsce Data Unit is the unit of iiifomiatton trarisfiir^ 
red across the service access point between an (JV + 1) entity 
and an (JV) entity in a single interaction. The si*e of (JV) 




Fig, 10, Interrslationsbip between data units. 



interface data units Is not necessarily the same at eaeti end of 
the connection. 

(JV - 1) Service Data Unit Is the amount of (JV ^ 1) inter- 
face data whose identity is preserved from one end of an 
(iV ~ 1) connection to the other. Data may be held within a 
connection until a complete service data unit is put into the 
connection. 

Expedited (JV ^ 1) service data unit is a smatl {N - .1) 
senrice data unit whose transfer is expedited. The (JV 1) 
layer ensures that an expedited data unit will not be delivered 
after any subsequent service data unit or expedited data unit 
sent on that connection. An expedited (JV - 1) service data 
unit may also be referred to aa an (JV - 1) expedited data 
unit, 

JVisre: An (JV) protocol data unit may be mapped one-to- 
one onto an (JV — 1) service data unit (see Pig. II). 

V. MANAGEMENT ASPECTS 

Even though a number of resources are managed locally, 
i.C„ without involving cooperation between distinct systems. 
Some management functions do. 

Examples of such management functions are 

configuration information, 
cold start/termination, 
monitoring, 
diagnostics, 
reeoftfigiiiatlon.etc. 

The OSl Atchltectuie considers management functions as 
■appljestions of a specific type. Management entitias located 
tn the highest layer of the architecture may use the complete 
set of services offered to al] applications In order to perforin 
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Fig. U, Logical ralationship htty/tm data unitj in adjacent layers. 



majiagement functions. This organization of management 
functions within the OSl Architecture is illustrated in Fig. 



VI. THE SEVEN LAYERS OF THE OSI ARCHITECTURE 
A, Justification of the Seven Layers 

ISO determined a ciumbef of pfinciples to be considered 
for defining the specific set of layers in the OSI architecture, 
and applied those principles to come up with the seven layers 
of the OSI Architecture. 

Principles to be considered are as follows. 

1) Do not create so many layers as to make difficult the 
system engineering task describing (ind integrating these 

2) Create a boundary at a point where the services descrip- 
tion can be small and the number of interactions across the 
boundary fs minimized. 

3) Create separate layers to handle functions which are 
manifestly different in the process performed or the tech- 
nology Involved. 

4) Collect similar functions into the same layer. 

5) Select boundaries at a point which past experience has 
demonstrated to be successful. 

6) Create a layer of easily localized functions so that the 
layer could be totaly redesigned and its protocols changed in 
a major way to take advantages of new advances in archi- 
tectural, hardware, or software technology v/ithout chargine 
the serdces and interfaces with the adjacent layers, 

7) Create a boundary v^'herc it may be useful at some point 
in time to have the corresponding interface Standardized. 

8) Create a layer when there is a need for a different level 
of abstraction in the handling of data, e.g., morphology, 
syntax, semantics. 

9) Enable changes of functions or protocols withiii a layer 
without affecting the other layers. 

10) Create for each layer Interfaces with its upper and 
lower layer only, 

11) Create further subgrouplng and organisation of func- 
tions to form sublayere within a layer in cases where distinct 
communication services need it. 

12) Create, where needed, two or more sublayers with a 



Fig. 1 2, A roprcjentatioii of management fujictiorts. 

common, and therefore minimum, functionality to allow 
interface operation with adjacent layers, 
13) AUow bypassing of Sublayers. 

B. Specific Layers 

The following Is a brief explanation of how the layers 
were chosen. 

1) It is essential that the architecture permits usage of a 
realistic variety of physical media for interconnection with 
different control procedures (e.g., V.24, V.35, X.21, etc.). 
Application of principles 3, 5, and 3 leads to identification 
oi a Physical Layer as the lowest layer jn the architecture. 

2) Some physical communications media (e.g., telephone 
line) require specific techniques to be used in order to trans- 
mlt data between systems despite a relatively high error rate 
.(Le., an error rate not acceptable for the great majority of 
applications). These specific techniques are used in dataJink 
control procedures which have been Studied and standardized 
for a number of years. It must also be recognized that new 
physical communications media (e.g., fiber optics) will re- 
quire different data-link control procedures. Application 
of principles 3, S, and 8 leads to identification of aZtors 
link Layer on top of the Physical Layer in the architecture. 

3) In the Open Systems Architecture, some systems will 
act as final destination of data. Some systems may act only as 
intermediate nodes (forwarding data to other systems). Apph- 
cation of principles 3, S, and ,7 leads to identification of a 
Network Layer on top of the Data Unk Layer. Network-oriented 
protocols such as routing, for example, will be grouped in this 
layer. Thus, theNetworl4 Layer will provide a connection path 
(network connection) between a pair of transport entities 
(see Fig. 13). 

4) Control of data transportation from source end system 
to destination end system (which need not be performed in 
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Fig, 1 3. The sovcn layers 051 arChiteeti"*. 



ifitemiediate nodes) is the last function to be pcrformecl in 
order to provids the totality of the transport service. Thus, 
the upper layer in the transport-service part of ths architec- 
ture is the Transport Layer, sitting on top of the Network Layer. 
This Trsnsport Layer relieves higher layer entities from any 
concern with the transportation of data between them. 

5) In Order to bind/unblfid distributed activities into a 
logical relationship that controls tht data ejtphangt with, 
respect to Synchronization and structure, the need for ii 
dedicated layer has been Identified. So the application if 
principles 3 and 4 leads to the establishment of the Session 
Layer which la on top of the Transport Layer. 

6) The remaining set of general interest fyndions ar* fh05c 
related to representation and manipulation of structured 
data for the benefit of application programs. Application 
of principles 3 and 4 leads to identification of a Presentation 
Layer on top of the Session Layer. 

7) Finally, there are applications ccnsistinE of application 
processes which perform information processing. A portion 
of these application processes and the protocols by which 
they communicate comprise the Application Layer as the 
highest layer of the architecture. 

The lesulting archlteetufe with seven layers, illustrated in 
Fig, 13 obeys principles 1 and 2. 

A more detailed definition of each of the seven layers 
identified above is given in the following sections, starting 
from the top with the application layer described in Section 
Vl-Cl) down to the physical layer described in Section VI-C7). 

C. Overview of the Seven Layers of the OSI Architecture 

1) TTte Application Layer: This is the highest layer in the 
OSl Architecture, Protocols of this layer directly serve the end 
user by providing the distributed infomiatioti service appro- 
priate to an application, to its management, and to system 
management, Management of Open Systems Interconnection' 
comprises those functions required to initiate, maintain, 
terminate, and record data concerning the establishment of 
connections for data transfer among .application procosscs. 
The other layers ejcist only to support this layer. 

An apphcation is composed of cooperating upplication 
processes which intercommunicate according to application 
layer protocols. Application processes are the ultimate source 
and sink for data exchanged. 

A portion of an application process is manifested in the 
application layer as the execution Of application protocol 
Ci,e., application entity). The rest of the application process 
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is considered beyond the scope of the present layered model. 
Applications or application processes may bs of any Idnd 
(manual, computerized, industrial, or physical), 

7) The Presentation Layer. The purpose of the Presentation 
Layeris to provide the set of serviecs which may be selected 
by the Appllcstion Layer to enable it to interpret the meaning 
of the data exchanged. These services are for the management 
of the entry exchange, display, and control of Structured 
data. 

The presentatioti service is location-independent and is 
considered to be on top of the Session Layer which provides 
the service of linking a pair of presentation entities, 

Jt (s through the use of services provided by the Presenta- 
tion Layer that applications in an Open Systems Intercon- 
nection environment can communicate without unacceptable 
costs in interface variability , transformations, or application 
modification, 

3) The Session Layer. The purpose of the Session Layer is 
to assist in the support of theititeractions between cooperating 
presentation entities. To do this, the Session Layer provides 
services which are classified into the following two categories. 

a) Binding two presentation entities into a relationship 
and unbinding them, Tliis is called session administration 
service. 

b) Control of data exchange, delimiting, and syn- 
chronizing data operations between two presentation entities. 
This is called sesaipn dialogue service. 

To implement the transfer of data between presentation 
entities, the Session Layer may employ the services provided 
by the Transport Layer. 

4) JTie Trampart Layer'. The Transport Layer exists to pro- 
vide a universal transport service in association with the under- 
lying services provided by lower layers. 

The Transport Layer provides transparent transfer of data 
between session entities, The Transport Layer relieves these 
session entitles from any concern with the detailed way In 
which reliable and cost-effective transfer of data is achieved. 

The Transport Layer is required to optimise the use of 
available communications services to provide the performance 
required for each connection between session entities at a 
minimum cost. 

, 5) The Network Layer: The Network Layer provides func- 
tional and procedural means to exchange network service 
data units between two transport entities over a network 
connection, it provides transport entities with independence 
from routing and switching considerations, 

6) The Data Link Layer. The purpose of the Data llnlt Layer 
is to provide the functional and procedural means to establish, 
maintain, and release data links between network entities, 

7) The Physical Layer: The Physical Layer provides mech- 
anical, electrical, functional, and procedural ohBractcrlstlcs 
to establish, maintain, and release physical connections (e.g., 
data circuits) between data link entities. 

VII. OSI PROTOCOLS DEVELOPMENTS 

The model of OSI Aicliltectuie defines the services pro- 
vided by each layer to the nest higher layer, snd offers con- 
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cepts to be used to specify how aach layer performs its 
specific functions. 

Detailed functioning of each layer is defined by the pioto- 
cols specific to the Uyet in the framework of the Architecture ! 
model. 

Moat of the initial effort within ISO has been placed on 
the model of OSI, The next step consists of the definition 
of standard protocols for each layer. 

This section contains a brief description of a likely initial 
set of protocols, corresponding to specific standardization 
projects recommended by SCl6, 

A. Protocols in the Physical f^yer 

Standards already exist within CCITT defining: 

1) interfaces with physical media for OSI, and 

2) protocols for establishing, controlling, and releasing 
switched data circuits, 

Such standards are, described in Other papers in this issue 
[9], (10].c.B.,X.3I,V,24.V,35,ctc. 

The only work to be dofit Will consist of clearly relating 
those standards to the OSI Architecture model, 

B. Protocols in the Data link Layer 

Standard protocols for the Data link Layer have already 
been developed nvitJltn ISO, which are described In other 
papers within this Issue [11] , [12] , ■ 

The most popular Data link Layer protocol is likely to be 
HDLC [13], without ruling out the possibility of using also' 
other character-oriented standards. 

Just as for the Physical Layer, the remaining work wiU 
consist plainly of clearly relating these existing standards 
to the OSI Architecture model. 

C Protocols in the Network layer 

An ijnportant basis for protocols in the network layer is 
level 3 of theX,25 Interface [14] defined by CClTT and 
described in anotJier paper in this issue. It wiU have to be 
enhanced in particular to permit interconnection of private 
and public networks. 

Other types of protocols are likely to be standardized 
later in this layer, and in particular, protocols corresponding 
to Patagram networks [10] , 

D. Protocols in the Transport Layer 

No standard exists at present for this layer; a large amount 
of experience has been accumulated in this area and several 
proposals itt avaiiflble. 

The most widely known proposal is the Trarapon Protocol 
proposed by IF|P and known as INWG 96.1 [15], which 
could sem as a basis for defining an international standard, 

S. Protocols for the SesHan Layer ,,. 

No standard existi and no proposal has been currently 
available, since in most networks, session functions were 
often considered as part of higher layer functions such as 
Virtual TennlnaJ and File Transfer. 

A standard Session Layer Protocol can easily b* extracted 
from existing higher layer protocols. 
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F, Presentation Layer Protocol 

So far, Virtual Terminal Protocols and part of Virtual File 
are considered the most urgent protocols to be developed in 
the Presentation Layer, 

A number of VTP's are available (e,e„ [16] , [17]), many 
of them being very similar, and it should be easy to derive a 
Standard VTP from these proposals, also making use of the 
ISO standard for "Extended Control Characters for I/O 
Imaging Dev[ces" [18). These protocols ate reviewed in 
another paper in tills issue [19] , 

The situation is similar for File Transfer Protocols. 

G. Management Protocols 

Most of the work within ISO has been done so far on the 
architecture of management functions, and very little work 
has been done on management protocol^ themsetvSB. There- 
fore, it Is too early to give indications on the Ufcely results 
of the ISO work in this area. 

vrn. CONCLUSION 

The development of OSI Standards is a very big shallenae,, 
the resuh of which will impact all future compilter com- 
munication developments. If standards come too latp or are 
inadequate, interconnection' of heterogeneous systems will 
, not be possible or wOl be very costly. 

The work collectively achieved SO .far by SCI 6 tnembers 
is very promising, and additional efforts should be expended 
to capitalize on thona initial results and some up rapidly with 
the most urgently needed set of Standards which will. Support 
initial usage of OSI (innalnly terminals accessing sendees and 
file transfers). The next set of standards, including OSI 
management and access to distributed data, ivill have to 
follow very soQH. 

Common standards between ISO and CCITT are also 
essentia! to the success of standardization, since ociv services 
announced by PTT's and common carriers ire vety similar 
to data processing services offered as computer manufacturer 
products, and duplication of now compatible standards 
could simply cause the standardization effort to fall, tn this 
regard, acceptance of the pSI Reference Model by CCITT 
Rapporteur's Group on Layered Architecture for Pul^Uc 
Data Networks Services is most promising. 

It is essentia] that all partners in this stsndardlzation 
process expend their best effort so it wQl be successful, and 
the benefits can be shared by all users, manufacturers of 
temiinals and computers, and the PTT's/commcm carriers. 
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OSI model 



From Wikipedia, the free encyclopedia 

The Open Systems Interconnection Basic Reference Model {OSI Reference Model ov OSI 
Model for short) is a layered, abstract description for communications and computer 
network protocol design, developed as part of Open Systems Interconnection (OS!) 
initiative!, It is also called the OSI seven layer model. The layers, described below, are, 
from top to bottom, Application, Presentation, Session, Transport, Network, Data Link and 
Physical 



OSI Model 

7 Application layer 
6 Presentation layer 
5 Session layer 
4 Transport layer 
3 Network layer 
2 Data link layer 



Even though newer IETF and IEEE protocols, and indeed QSI protocol work subsequent to 

the publication of the original architectural standards haVc largely superseded it, the OST „ llq sublayer 

model is an excellent place to begin the study of network arichitecture. Not understanding . MAC sublayer 

that the pure seven-layer model is more historic than current, inany beginners make the ^ physical layer 

mistake of trying to fit every protocol they study into one of the seven basic layers. This is - - " 

not always easy to do as many of the protocols in use on the Internet today were designed as part of the TCP/IP model, 
and may not fit cleanly into the OSI model. 
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History 

In 1977, the International Organization for Standardization (ISO), began 
two major components: an abstract model of networking (the Basic ~ 
of concrete protocols, The standard documents that describe OSI are for 



Parts of OSI have influenced Internet protocol development, but none 
in ISO 7498 and its various addenda. In this model, a networking systeiin 
or more entities implement its functionality. Each entity interacts 
and provides facilities for use by the layer above it. 



In particular, Internet protocols are deliberately not as rigorously aichit 
of the TCP/IP model splits it into four layers. The Internet Application 
Presentation Layer, and most of the Session Layer. Its End-to-End Layiir 
OSI Session Layer as well as the Transport Layer. Its Internetwork Layst 
while its Interface layer includes the OSI Data Link and Physical Layeijs, 
seven-layer protocol model as defined in ISO 7498, rather than 
of the Network Layer document. 



to develop its OSI networking suite. OSI has 
Model, or seven-layer model), and a set 
sale and not currently available online, 

)re than the abstract model itself, documented 
is divided into layers. Within each layer, one 
directly only with the layer immediately beneath it, 



as the OSI model, but a common version 
:.ayer includes the OSI Application Layer, 
includes the gracetijl close function of the 
is equivalent to the OSI Network Layer, 
These comparisons are based on the original 
ns in such things as the Internal iDtganization 
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entity 



Protocols enable an entity in one host to interact with a corresponding 
definitions abstractly describe the functionality provided to a (N)-!ayer tiy 
layers inside the local host. 

Description of OSI layers 



Layer 7: Application layer 

The application layer is the seventh level of: 
the seven-layer OSI model. It interfaces 
directly to and performs common 
application services for the application 
processes; it also issues requests to the 
presentation layer. Note carefully that this 
layer provides services to user-defined 
application processes, and not to the end 
user. For example, it defines a file transfer 
protocol, but the end user must go through 
an application process to invoke file 
transfer. The OSI model docs not include 
human interfaces. 



Data unit Layer 

: Application : Network, process 
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at the same layer in a remote host. Service 
an (N-l) layer, where "N is one of the seven 



OSI Model 
i Function 



application 

Htf^t Data Presentation^ Data representation and encryption 
layers , Session ; interhost communication 

Segments ; Transport ; End-to-end connections and reliability (TCP) 
Packets Network I Path dcttrtn I nation and logical addressing (IP) 
Fram.es ' Data link ! Pliysical addressing (MAC &. LLC) 
Bits ■ ' physical j Media, signal and binary transmission 



layers 



The common application services sublayer provides functional elementSi 
Element (comparable to Internet Remote Procedure Call), Association 
to the ACID requirements). 



including the Remote Operations Service 
Ctontrol, and Transaction Processing (according 



Above the common application service sublayer are functions meaningful 
messaging (X.400), directory (X,500), file transfer (FT AM), virtual te 
(JTAM). 

Layer 6: Presentation layer 



The Presentation layer transforms the data to provide a standard interface 
data encryption and similar manipulation of the presentation are done at " 
protocol that the developer sees fit. Examples of this layer are converting 
coded file, or serializing objects and other data structures into and out 

Layer 5: Session layer 



for the Application layer. MIME encoding, 
this layer to present the data as a service or 
an EBCDIC-coded text file to an ASCII- 



The Session layer controls the dialogues/connections (sessions) betweeii 
terminates the connections between the local and remote application. It p 
operation, and establishes checkpointing, adjournment, termination, anc 
layer responsible for "graceful close" of sessions, which is a property " 
recovery, which is not usually used in the Internet protocols suite. " 
environments that make use of remote procedure calls (RPCs). 



iSCSI, which implements the Small Computer Systems Interface 
layer protocol increasingly used in Storage Area Networks and internal' 
storage devices. iSCSl leverages TCP for guaranteed delivery, and catr 
payload to create a vinual SCSI bus between iSCSI initiators and iSCSl 

Layer 4; Transport layer 



I to user application programs, such as 
(VTAM), and batch job manipulation 



computers. It establishes, manages and 
provides for either full-duplex or half-duplex 
restart procedures, The OSI model made this 
otTCP, and also for session checkpointing and 
layers are commonly used in application 



(SCSI) encapsulated into TCP/TP packets, is a session 
y between processors and high-performance 

SCSI command descriptor blocks (CDB) as 
targets. 
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The Transport layer provides transparent transfer of data between end 
the upper layers. The transport layer controls the reliability of a given 
segmetitation/desegraentation, and error control. Some protocols are sta 
transport layer can keep track of the segments and retransmit those that 
protocol is the Transmission Control Protocol (TCP). The transport layei 
segments or User Datagram Protocol (UDP), Stream Control Transmission 
easy way to visualize the Transport Layer is to compare it with a Post 
classification of mail and parcels sent, Do remember, however, that a 
Higher layers may have the equivalent of double envelopes, such as 
read by the addressee only, Roughly speaking, tunneling protocols operate 
IP protocols such as IBM's SNA or Novell's IPX over an IP network, or 
Generic Routing Encapsulation (ORE) might seem to be a network layei 
takes place only at endpoint, GRE becomes closer to a transport protocol 
frames or packets to deliver to an endpoint. L2TP carries PPP frames ' 

Layer 3; Network layer 



providing reliable data transfer services to 
through flow control, 

and connection oriented. This means that the 
lil. The best known example of a layer 4 
is the layer that converts messages into TCP 
Protocol (SCTP), etc. packets. Perhaps an 
Office, which deals with the dispatch and 
office manages the outer envelope of mail. 

lie Presentation services that can be 
at the transport layer, such as carrying non- 
end-to-end encryption with IPsec. While 
layer protocol, if the encapsulation of the payload 
that uses IP headers but contains complete 
inside transport packets. 



nlirik 



cryptographic 



Tlie Network layer provides the functional and procedural means 
source to a destination via one or more networks while maintaining the 
layer. The Network layer performs network routing functioiis, and might 
and report delivery errors. Routers operate at this layer— sending data ' 
the Internet possible. This is a logical addressing scheme - values are 
scheme is hierarchical. The best known example of a layer 3 protocol is 
visualize this layer as managing the sequence of human carriers taking 
trucks that carry sacks of mail to other post offices or airports, airplanes 
that distribute mail sacks in a city, and carriers that take a letter to its ' 
large document into smaller envelopes for shipping, or, in the case of the 
transport record into packets. 

Layer 2: Data Link layer 

The Data Link layer provides the functional and procedural means to treLisfer data between network entities and to 
detect and possibly correct errors that may occur in the Physical layer. The best known example of this is Ethernet. 
This layer manages the interaction of devices with a shared medium. Other examples of data link protocols are HDLC 
and ADCCP for point-to-point or packet-switched networks and Aloha for local area networks. On IEEE 802 local 
area networks, and some non-IEEE 802 networks such as FDD!, this laj-er may be split into a Media Access Control 
(MAC) layer and the IEEE 802.2 Logical Link Control (LLC) layer. It slrrangcs bits from the physical layer into 
logical chunks of data, known as frames, 
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of trarisferring variable length data sequences from a 
quality of service requested by the Transport 
also perform fragmentation and reassembly, 
tflroughout the extended network and making 
cPosen by the network engineer. The addressing 
the Internet Protocol (IP). Perhaps it's easier to 
letter from the sender to the local post office, 
that carry airmail between major cities, trucks 
destinations. Think of fragmentation as splitting a 
network layer, splitting an application or 



This is the layer at which the bridges and switches operate. Connectiviti/ 
network nodes forming layer 2 domains for unicast or broa.dcast forwarc" 
data Frames to create tunnels and logically separated layer i forwarding 



is provided only among locally attached 
forwarding. Other protocols may be imposed on the 
domain. 



The data link layer might implement a sliding window flow control and acknowledgment mechanism to provide 
reliable delivery of frames; that is the case for SDLC and HDLC, and derivatives of HDLC such as LAPB and LAPD. 
In modern practice, only error detection, not flow' control using sliding Window, is present in modem data link 
protocols such as Point-to-Point Protocol (PPP), and, on local area netwoi " ' 

most protocols on Ethernet, and, on other local area networks, its flow Control and acknowledgment mechanisms are 
rarely used. Sliding window flow control and acknowledgment is used kthe transport layers by protocols such as 
TCP. 

Layer 1: Physical layer 
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f^r 



Tlie Physical layer defines all the electrical and physical specifications 
relationship between a device and a physical med'iumJThis. iiicliides the 
specifications. Hubs, repeaters, network adapters and Hosti^us Adapters 
physical-layer devices. 



devices. In particular, it defines the 
layout of pins, voltages, and cable 
(HBAs used in Storage Area Networks) are 



To understand the function of the physical layer in coiatrast to the 
layer as concerned primarily with the interaction of a single device with 
concerned more with the interactions of muhiple. devices (i.e., at least 
will tell one device how to transmit to the medium, and another device 
protocols, how to gain access to the medium. Obsolescent physical layei 
wires to control access to the medium. 

The major functions and services performed by the physical layer are: 



functions of the data link layer, think of the physical 
a medium, where the data link layer is 
two) with a shared medium. The physical layer 
now to receive from it, but not, with modern 
standards such as RS-232 do use physical 



I Establishment and termination of a connection to a communications 
I Participation in the process whereby the communication resourced 

For example, contention resolution and flow cotitrol. 
I Modulation, or conversion between the represeiiitation of digital data 

signals transmitted over a communications chartne), These are signal! 

as copper and optical fiber) or over a radio link, 



Parallel SCSI buses operate in this layer, although it iTiust be remembered 
layer protocol that runs over this bus.. Various phy si caM ay er Ethernet s 
incorporates both this layer and the data-link layer. The same applies to 
FDDI, and IEEE S02.1 1, as well as personal area HietWi-kSifeUch as'"" 



that the logical SCSI protocol is a transport- 
standards are also in this layer; Ethernet 
other local-area networks, such as Token ring, 
and IEEE 802.15.4. 



Mnemonics 



« Please Do Not Throw Salami Fi^za Away. ^ this works for 

■ AH People Seem To Need Data Processing: —la top-to-bottom 

■ APS Transports Network Data Physically. — APS refers to AppH 
separates the upper and lower layer groups. 

■ please Do Not Tell Secret Passwords Anytime, — Another bottom-to-top phrase 



Interfaces 



In addition to standards for individual protocols in transmission, there . 
to talk to the ones above or below (usually operating^sy stem-specific), 
and Unix's Berkeley sockets and System V Transport' Layer Interface, 
above) and the transport (layer 4). NDIS and ODI are interfaces betweejn 
(layer 3). 



OSl Service Specifications are abstractions of functionality commonly 



Examples 



Layer 
Name 



Misc. 
examples 



I 

7 i Application 



TCP/IP 
suite 

I DHCP, DNS, 
: FTP, Gopher. 
.HTTP, NFS, 
NTP,RTP, 



^AppleTalkj 
I suite 



jModbus, S1P, :SMPP, 



ISUP, iAFP 

INAPJ 

MAP, 



!k.50o, 
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medium. 

are effectively shared among multiple users. 



in user equipment and the corresponding 
Is operating over the physical cabling (such 



-to-top (layer 1 to 7). 
reminder (layer 7 to 1). 
location, Prsasntation, and Session. This one 



also interface standards for different layers 
For example, Microsoft Windows' Winsock, 
! interfaces between applications (layers 5 and 
the media (layer 2) and the network protocol 



present in programming interfaces. 



IPX 

suite 
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i 1 iTDl, ASCII. 

L ' , ! EBCDIC, 
|6: Presentation i^^j^j 

i j 'MPEG 



; Named 
! Pipes, 
; NetBIOS, 
SAP, SOP 



4 ! Transport 



jNBF, 

InanoTCP, 

^nanoUDP 



3 i Network ■NBF,Q-931 



802.3 

i (Ethernet), 

;802.11a^/g/n 
MAC/LLC, \ 
802.1Q i 

;(VLAN), ! 

iATM.CDP, I 

!fDDI, Fibre ! 

■Channel, ! 

i Frame Relay, 
HDLCISL, 
PPP,Q.92I, ; 

i Token Ring ; 

RS-232. 
V.35.V-34, i 
1.430,1.431, i 
Tl.EI, 
lOBASE-T, I 
! lOOBASE- 
':TX, POTS, 
SONET, 
,DSL. 

■802,lla/b/g/n 
PHY 



iglyfXP, 


iTUP, 


SNMP, 


Itcap 


Telnet 





MIME 




iXDR. SSL. 




iTLS(Nota 




separate 




■layer) 




Sockets. 




; Session 




i establishment; 


iin TCP. SIP. 


1 


(Not a 




separate 




layer with 




■standardized 




:AP1,) 




TCP, UDP, 




SCTP 




TP,ICMP, 


MTP- 


! IPsec, ARP, 




iRIF. 03PF 


SCCP 



IISO 

|S823, 

;X.226 



ASP, 
ADSP, 
'Z.\P, PAP 



iATP, NBP, 
iAEP, 

[rtmp 



PPP, SLIP. 
PPTP, L2TP 



MTP- 

;2 



1 ' Physical 



ISO 

8327, 

X.225 



ITPO, 
:TP1, 
iTP2, 

ItP3,TP4| 
Tx'^25 ^ 
(PLP), jlPX 
■CLNP ! 



ISPX 



I 



LocalTalk, 

TokeiiTalk, 

lEt'het'fafk, ■ 

ApplcTalk 

Remote 

Access, 

PPP 



X,25 
(LAPB), 
Token 
Bus 



I 



IEEE 

802.3 

framing, 

Ethernet 

11 

framing 



RS-232, 
RS-422, 
STP, 

PhoneNct 



! 

IX.25 
j(X.21bis, 
lEIA/TIA- 
;232, 
EIAmA- 
{449, 

!ETA-530, 
GJ03) 



RRC (Radio 
Resource Control) 



RLC (Radio Link 
Control), MAC 
(Media Access 
Control), PDCP 
(Packet Data 
Convergence 
Protocol) afid 
Broadcast/Multicast 
Control (BMC). 



UMTS LI (UMTS 
Physical Layer) 



See also 



. TCP/TP model 

■ Internet protocol suite 

■ List of network protocols 



httpi//en.-wikipedia.org/w/index,php?title=OSJLmoc!el&printable=yes 



7/10/2007 



07/10/2007 16:46 6517351102 
OSl model - Wikipedia, the free encyclopedia 



SHUMAKER & SIEFFERT 



PAGE 40 

Page 6 of 6 



■ OSl protocols 
i Node 

External links 

i ISO standard 7498-1:1994 (ZIP format) 

■ Cybenelccom — Layered Model of Regulation! _ 

■ OSl Reference Model — The ISO Model of Arihitecture for Open Systems Interconnection PDF (776 KiB), 
Hubert Zimmermann, IEEE Transactions on Cdmmiinications, vol. 28, no. 4, April 1980, pp. 425 - 432. 

■ Internetworking Basics 

m osiTlayerxom Amusing list of OSl mnemonics 
Retrieved from ''http;//en,wikipcdia,org/wiki/OSl_nio|der' . ; , 

Categories: CTSSP | Network arcliitecturc | ISO startdirds j ITU-T recommendations | OSl protocols | Reference 

models „^ „^ - — 

» Tills page was last modified 20:19, 7 July 20071 

■ All text is available under the terms of the GNU Free Documentation License. (See Copyrights for details.) 
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a US-registered 501(c)(3) tax- 
deductible nonprofit charity. 
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APPENDIX III; RELATED PROCEEDINGS 

None 
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